Systems are designed, deployed and operated for the benefit of one or more stakeholders. A stakeholder is any person or group within an organization which will be affected in some way in the implementation, operation, updating, or maintenance of the system. For example, in a system designed for operations and support of those operations, stakeholders may include groups representing engineering, maintenance, logistics, finance and operations. Any change or update to the system or any part thereof, may have effects that ripple through the organization and impact one or more stakeholders in some way.
As systems are developed, the goals and objectives of the stakeholders are taken into consideration and the processes designed for the system are directed to meeting the goals and objectives of the stakeholders. In larger organizations, the processes may become complex, and the corresponding systems grow in complexity proportionately. Further, as organizations grow, systems may be deployed at geographically dispersed locations. Based on the location and other factors, different system configurations used across the organization may evolve.
Independently operating groups may have responsibility for specific aspects of a system. Multiple independent groups may represent sub-systems or system components which function to define an overall operations system producing an integrated product. Therefore, each group or integrated product team (IPT) may develop and maintain information specific to a segment or product line of an overall system. This information may be maintained independently of information maintained by other IPTs involved in the same overall system.
In order for a stakeholder to derive the intended benefit from the system, it is imperative that the system be maintained in a state of operational readiness. To achieve this, hardware and software components which constitute the system must be maintained in working condition. Parts that break, wear out, or are recalled, must be removed from the system and/or repaired and replacement parts reinstalled. During the time it takes to remove a part and receive and install the replacement part, the system operates, if at all, at a diminished capacity.
Another factor integral to the overall value of a system is the cost of ownership. The cost of ownership of a system refers to the total costs of deploying, operating and maintaining a system throughout the entire life cycle of the system. System sustainment costs may contribute to over 80% of the overall life cycle costs of a system. Some of the primary costs which impact system sustainment include the operational profile of the system, the reliability of system parts, and the supply chain architecture. Reliability is determined based on the failure rate of system parts and the ability to replace failed parts when needed. The supply chain architecture determines the availability of spare or replacement parts based on the location of the system relative to a repair depot. The minimization of system downtime and the overall cost of ownership can be competing factors which must be managed by the stakeholder to maximize system performance while insuring the system remains economically justifiable for the organization.
During system design, prior to deployment, the ultimate costs of factors such as system reliability and supply chain architecture are not known. This uncertainty creates challenges when designing systems for optimal benefit relative to dollars spent. System modeling is used to model the behavior of a proposed or existing system to determine future needs and costs of operations. Discrete event simulation (DES) provides a method of defining models that are representative of a system and defining various and inter-related environmental properties that occur when operating the system. In DES, events which occur within the constructed model involve state changes of various system components. These events may trigger other events downstream. As events are triggered, they are stored in an event log in chronological order. The logged events may reflect future state changes of one or more associated system components. As each event is simulated, the event list is updated with newly triggered events and is reordered according to the time sequence in which the events are modeled to occur.
There are commercially available DES software programs which include a DES engine for running a system model simulation. For example, Arena®, a DES application available from Rockwell Automation, Inc. of Milwaukee Wis. may be used to perform discrete event simulations. DES software packages, however, require the system model to be fully defined within the DES software. This requires the enlistment of software engineers well versed in DES programming to manually code the model into the DES applications. Conventional DES models use spreadsheets as inputs serving as a baseline from which the simulation is started. Relationships between system components are statically defined in the model and are used by the DES engine to simulate interdependent events that may affect multiple system components. When analysis of statistical data generated by the simulation indicates that adjustments or changes to the system model need to occur (e.g. component changes for what-if analysis), the model must be redefined through the source code that inserts the model into the DES software. Thus, the system model changes must be re-programmed manually by programmers proficient in the DES language. Creation of models in this manner, and the subsequent reprogramming that may be needed, are time consuming. Furthermore, these manual programming changes do not provide high fidelity analytic data due to their limited ability to define the complexities and interrelationships inherent in most systems.
When a system involves a number of IPTs, each IPT serves as a stakeholder. Each stakeholder has an intimate familiarity with his/her particular product line, and maintains detailed information regarding the product line. This detailed information may include DES modeling information for the product line, which is typically arranged in a spreadsheet format. In systems for the operation and support of military operations, IPTs may maintain information in a standardized format such as the military standard (MIL-STD). MIL-STD format establishes uniform engineering and technical requirements for military-unique or substantially modified commercial processes, procedures, practices, and methods. As a standard, MIL-STD provides a picture of system processes that are readily understandable between and among independent IPTs.
In a conventional DES configuration, the development of a system model requires extensive configuration in the form of programming to provide input data that is representative of the system being modeled. In complex systems, such as those systems involving multiple IPTs, programmers responsible for defining the DES model must translate the data received from the various product lines defining the system, and provide an accurate model definition which defines not only each individual product line, but the inter-relationships between multiple product lines in the overall system.
While programmers possess the skills to create the DES model, they do not necessarily possess the familiarity with a product line that the team responsible for that product line possesses. Therefore, a knowledge transfer from the team to the programmer must occur. This transfer of knowledge may be subject to misunderstanding, misinterpretation or omissions due at least in part, to the programmers' lack of familiarity with the product line.
A system which defines a system model for discrete event simulation without the disadvantages of requiring reprogramming is desired.